Server virtualization allows multiple virtual machines (VM) to run on a single physical server. Virtualization allows users to move their servers to a “cloud” and to take advantage of the flexibility and scalability offered by running services on VMs. However, some users are hesitant to move their services to a cloud due to concerns such as control over deploying services to the cloud, moving services to different cloud providers, and the capability to move services back to the user's own enterprise datacenter.
Existing virtual datacenters can make deployment of VMs labor intensive. Particularly, when the cloud hosters require users to change the IP addresses for services when the services are moved to the cloud environment. While this may appear to be a minor deployment detail, the IP address typically has real semantic meaning to an enterprise. Network, security, compliance, and performance policies often incorporate and are dependent on the actual IP address of a given service. Moving a service to existing cloud providers requires rewriting of all these policies to take into account the new IP addresses for the services. This can be difficult because the policies may be spread among a number of different organizations that control those policies. Each time a user moved to a different cloud provider, then the new host would assign a different set of IP addresses, which would require another policy rewrite. The current situation blocks many users and scenarios from adopting the cloud.
Users want their services in the cloud to appear similar to the services running in their internal datacenters. At the same time, users want the cloud services to adhere to existing policies and to provide isolation from other VMs running in the cloud hosting environment. In summary, users demand that cloud services are as isolated and as safe as if were running in the user's own datacenter. To fulfill user requirements, the cloud host should have the capability to provide networks among the VMs that allow users to maintain existing IP addresses.
Existing network-virtualization architecture provides only a single virtual subnet for a set of virtual machines (VMs). As a result, communications between VMs of different virtual subnets must go through one or more physical gateways or routers. This can be cumbersome to setup and introduces overhead when traversing external gateways or routers with server virtualization. An additional problem involves the management of a multi-subnet topology in a network virtualized datacenter, which requires both managing network virtualization policy on VM host and configuring a different set of network routes on the gateways/routers.